feat(module): Created PluginModule class for modular plugin lifecycle

• Created an abstract class PluginModule to better handle multiple modules within the plugin and to appropriately handle the lifecycle
      - Construct injected common fields such as OverlayManager, Client, and the config
      - Field injected on-demand fields such as EventBus and GameEventManager
      - Automatically (un)registers the module from the EventBus
      - Re-fire various events by utilizing GameEventManager#simulateGameEvents within #startUp
      - Abstracted #onStartUp to handle module starts, #onShutdown to handle module stops, and #isEnabled to determine the status of the module

refactor: Start refactoring RandomEventHelper to modular plugin lifecycle

• Removed prior injections that have yet to be refactored
• Refactored #startUp, #shutDown, and #onConfigChanged to utilize the new modular system to handle state changes

refactor(surpriseexam): Migrate SurpriseExamHelper to PluginModule lifecycle

• Refactored SurpriseExamHelper to the modular plugin lifecycle
  • Now extends PluginModule and implements respective methods, moving the existing start/stop login there
  • Use constructor injection and removed duplicate field injections
• Injected SurpriseExamHelper and added it to the pluginModulesMap

feat(PluginModule): Add #isLoggedIn to check if the player is logged in

feat(surpriseexam): Improve support for starting during active event

• Improved handling initial runs when (re)starting the plugin when already inside the Surprise Exam random event
  • Primarily for when the puzzle interface is already on screen

refactor(captarnav): Migrate PirateHelper to PluginModule lifecycle

• Refactored PirateHelper to the modular plugin lifecycle
  • Now extends PluginModule and implements respective methods, moving the existing start/stop login there
  • Use constructor injection and removed duplicate field injections
• Injected PirateHelper and added it to the pluginModulesMap

refactor(mime): Migrate MimeHelper to PluginModule lifecycle

• Refactored MimeHelper to the modular plugin lifecycle
  • Now extends PluginModule and implements respective methods, moving the existing start/stop login there
  • Use constructor injection and removed duplicate field injections
• Injected MimeHelper and added it to the pluginModulesMap

feat(mime): Improve support for starting during active event, overlay, refactor

• Improved handling initial runs when (re)starting the plugin when already inside the Mime random event
  • Primarily for when the emote button interface is already on screen
• Change Mime text when undetermined emote answer
• Use default font size for overlay
• Refactored Mime animation checks and answer updating into #updateMimeAnimation

Note, while testing the Mime module, I noticed that starting and stopping the refactored Gravedigger module (multiple times) seems to have overlay issues again when switching back to field injection for both overlays.

refactor(drilldemon): Migrate DrillDemonHelper to PluginModule lifecycle

• Refactored DrillDemonHelper to the modular plugin lifecycle
  • Now extends PluginModule and implements respective methods, moving the existing start/stop login there
  • Use constructor injection and removed duplicate field injections
• Injected DrillDemonHelper and added it to the pluginModulesMap

feat(drilldemon): Improve support for starting during active event

• Improved handling initial runs when (re)starting the plugin when already inside the Drill Demon random event
  • Fix race condition issue with events - primarily regarding #onGroundObjectSpawned and exerciseMatsMultimap

It's probably better to have kept the varbit initialization within #onNpcChanged, but I wanted to keep everything inline for the future. I want to handle varbit inits #onStartUp. Though looking back, I may have to reconsider this due to the way GravediggerHelper is implemented. Also, it does spam the log with 4/8 writes due to the varbit value being 0 and reaching

refactor(beekeeper): Migrate BeekeeperHelper to PluginModule lifecycle

• Refactored BeekeeperHelper to the modular plugin lifecycle
  • Now extends PluginModule and implements respective methods, moving the existing start/stop login there
  • Use constructor injection and removed duplicate field injections
• Injected BeekeeperHelper and added it to the pluginModulesMap

feat(beekeeper): Improve support for starting during active event

• Improved handling initial runs when (re)starting the plugin when already inside the Beekeeper random event
• Avoid constantly appending corresponding number to destination widget label

feat(captarnav): Improve support for starting during active event

• Improved handling initial runs when (re)starting the plugin when doing Capt' Arnav's Chest random event
• Add missing isSolved = false assignment within PirateChestSolver#isChestCorrectlySet

refactor(quizmaster): Migrate QuizMasterHelper to PluginModule lifecycle

• Refactored QuizMasterHelper to the modular plugin lifecycle
  • Now extends PluginModule and implements respective methods, moving the existing start/stop login there
  • Use constructor injection and removed duplicate field injections
• Injected QuizMasterHelper and added it to the pluginModulesMap

feat(quizmaster): Improve support for starting during active event

• Improved handling initial runs when (re)starting the plugin when doing Quiz Master random event

refactor(sandwich): Migrate SandwichLadyHelper to PluginModule lifecycle

• Refactored SandwichLadyHelper to the modular plugin lifecycle
      - Now extends PluginModule and implements respective methods, moving the existing start/stop login there
      - Use constructor injection and removed duplicate field injections
• Injected SandwichLadyHelper and added it to the pluginModulesMap

feat(sandwich): Improve support for starting during active event

• Improved handling initial runs when (re)starting the plugin when doing Sandwich Lady random event

Note, while testing the Mime module, I noticed that starting and stopping the refactored Gravedigger module (multiple times) seems to have overlay issues again when switching back to field injection for both overlays.

The issue was that I forgot to re-inject the gravediggerItemOverlay as a part of the refactor. As you can see from the snippets above, it was defined but never injected/created.

Also, in the future, this is a good reference to have: https://github.com/google/guice/wiki/CyclicDependencies

refactor(gravedigger): Migrate GravediggerHelper to PluginModule lifecycle

• Refactored GravediggerHelper to the modular plugin lifecycle
  • Now extends PluginModule and implements respective methods, moving the existing start/stop login there
  • Use constructor injection and removed duplicate field injections
    • Re-inject GravediggerOverlay
• Injected GravediggerHelper and added it to the pluginModulesMap

feat(gravedigger): Improve support for starting during active event

• Improved handling initial runs when (re)starting the plugin when doing Gravedigger random event
  • Removed reliance on #onGameTick and initiallyEnteredGraveDiggerArea
  • Allow the plugin lifecycle's #startUp and specifically GameEventManager#simulateGameEvents to handle re-posting events
    • Migrate over ItemContainerChanged and VarbitChanged re-posts and fetching of sprites/images to #onStartUp
• Removed unnecessary event listeners for GameTick and NpcSpawned

fix(gravedigger): Fix NPE when starting plugin with an empty grave

• Fix NPE that was thrown as a result of grave#getFilledGrave being null such as when starting the plugin with an empty grave
  • Now fetching either a filled or empty grave depending on which is available -> skipping if both null

refactor(maze): Migrate MazeHelper to PluginModule lifecycle

• Refactored MazeHelper to the modular plugin lifecycle
      - Now extends PluginModule and implements respective methods, moving the existing start/stop login there
      - Use constructor injection and removed duplicate field injections
• Injected MazeHelper and added it to the pluginModulesMap

refactor(maze): Remove now redundant cold start handling

• Removed no longer needed event listener for GameTick
• Removed no longer needed variables that help track first start or required for cold start support

fix(maze): Fix not clearing the current path when plugin is shutdown

refactor(freakyforester): Migrate FreakyForesterHelper to PluginModule lifecycle

• Refactored FreakyForesterHelper to the modular plugin lifecycle
      - Now extends PluginModule and implements respective methods, moving the existing start/stop login there
      - Use constructor injection and removed duplicate field injections
• Injected FreakyForesterHelper and added it to the pluginModulesMap

feat(freakyforester): Improve support for starting during active event

• Improved handling initial runs when (re)starting the plugin when doing Freaky Forester random event

fix(maze): Fix not showing path on restart, use instanced WorldPoint instead

• Fixed an issue where the Shortest Path wasn't properly calculated/rendered upon restarts/cold-starts
• Now uses the player's LocalPoint and converts it to an instanced WorldPoint (WorldPoint#fromLocalInstance) as the starting WorldPoint for the path generation
• Modified logging to reflect usage of point types

refactor(pinball): Migrate PinballHelper to PluginModule lifecycle

• Refactored PinballHelper to the modular plugin lifecycle
      - Now extends PluginModule and implements respective methods, moving the existing start/stop login there
      - Use constructor injection and removed duplicate field injections
• Injected PinballHelper and added it to the pluginModulesMap

feat(pinball): Improve support for starting during active event

• Improved handling initial runs when (re)starting the plugin when doing Pinball random event

I realized that I forgot about event race conditions. For example, when refactoring the Pinball module, even though I was calling ClientThread#invokeLater, sometimes my required variables were null/not populated due to that happening during game events such as GameObjectSpawned. The sequence would look like the following:

1. #onStartUp
2. ClientThread#invokeLater to initialize any other event data such as faking a VarbitChanged
3. --> In this case, it was doing this.activePinballPost = this.pinballPostsMap.get(value); but this.pinballPostsMap was null/not fully populated
4. Then #onGameObjectSpawned was fully triggered

I think it will be a good idea to reference back to any event that had to fake sending events on startup and specifically Varbit related events.

WidgetLoaded

• Beekeeper
• Capt' Arnav's Chest
• Mime
• Sandwich Lady
• Surprise Exam
• Quiz Master

VarbitChanged

• Drill Demon
  • Unlike the Pinball module, when I was testing cold-starts for Drill Demon module, it was working properly. We should be safe to consider this as not having a problem due to way this module is coded.
    • #onStartup -> #onVarbitChanged updates exerciseVarbitMatMultimap, which is later referenced by #onChatMessage - The required referenced data is stored and therefore safe
• Gravedigger
  • I believe at some point I may have experienced an issue here, but I could've sworn I fixed it.
    • #onStartup -> #onVarbitChanged which calls #updateRequiredCoffin and #updatePlacedCoffin which both modifies graveMap - graveMap is referenced in #onGameObjectSpawned; however, in both event subscribers, we're always checking to see if there is a respective found within graveMap and initializing it if not, so there should be no problems
      • #onVarbitChanged uses getOrDefault(graveNumber, new Grave(graveNumber));
      • #onGameObjectSpawned null checks - if null -> initialize -> update -> store
• Pinball

fix(drilldemon): Use #invokeLater to fix possible race conditions

• Other modules rely on #invokeLater, so this also maintains consistency